home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Dec 90 / MacApp.Tech$ 12⁄21⁄90 / 2538-Re Performance HELP!-Dec90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  3.9 KB  |  89 lines  |  [TEXT/GEOL]
  1. Item    6683697                         19-Dec-90        17:05PST
  2.  
  3. From:   MADA.SYSOP                      MacApp Dev Assoc, Don Sawtelle,IVC
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. ------------------------------------------------------------------------------
  8.  
  9. Sub:    re: Performance HELP!
  10.  
  11. [From TerranVW on America Online at 90-12-18 18:38:05 EST]
  12.  
  13. Michael, this is probably the memory manager bug in the new ROMs
  14. there's been quite a bit of traffic on A'link about this. quoting
  15. from one link titled "Slow IIci Memeory Mgr'
  16.  
  17. Dick Startz (TSP.STARTZ) responds:
  18. ---
  19. I've had exactly the same situation with the IIci using NewPtr rather than
  20. handles.  I've documented it and asked DTS for advice.
  21. ---
  22.  
  23. Well, I think that this one has finally been nailed down. When dealing with
  24. Memory Management on the Macintosh, there is a lot of problem dealing with
  25. cause and effect. With as many changes as there were in the ROMs on the IIci
  26. (and IIfx, IIsi, and LC), it's not easy to determine if the problem is with the
  27. Memory Manager or elsewhere (for instance, with some toolbox routine
  28. fragmenting the heap).
  29.  
  30. After Dick sent in his request to DTS, I spent a few late hours at work trying
  31. to track it down. By carefully controlling the environment the application ran
  32. under, it became apparent that the problem was definitely a bug in the Memory
  33. Manager on those four machines. Those ROMs are referred to as the "32-bit
  34. clean" ROMs, and are identified with the ROM version $67C. (Dick, by now, you
  35. should have your response from DTS describing the problem in detail).
  36.  
  37. The fix for this is not going to be simple. The bug is at the very core of the
  38. Memory Manager. Because the Memory Manager is not vectored aside from its entry
  39. points, and because it is self contained, there are no places for a patch to be
  40. hooked in. It is possible that if a fix is put in place, it will have to be
  41. done by replacing the entire Memory Manager (about 9K).
  42.  
  43. Characteristics of the problem:
  44. -------------------------------
  45. In many of the Memory Manager's operations, it needs to find blocks of free
  46. space. Rather than perform an exhaustive search on the entire heap every time,
  47. the Memory Manager maintains a hint that it stores in the zone header
  48. (AllocPtr). When looking for free space, the Memory Manager starts at the block
  49. pointed to by AllocPtr, proceeding to the end of the heap. If it doesn't find a
  50. block of free space large enough, it starts over from the beginning of the
  51. heap.
  52.  
  53. The problem is that AllocPtr sometimes gets set with Master Pointer bits in the
  54. high byte. When the comparison is made to see if the pointer is past the end of
  55. the heap, the result always indicates that we HAVE past the end of the heap,
  56. and the search is restarted from the beginning. Hence, we get a performance
  57. degradation.
  58.  
  59. You may be able to structure your program to avoid this problem as much as
  60. possible. If you can arrange your heap such that relatively few objects are
  61. locked low in memory, or if you can limit your use of non-relocatable blocks
  62. (which are placed low in memory), you can limit the effects of the bug. By
  63. reducing the number of blocks low in the heap, you reduce the speed impact
  64. caused by starting a free block search at the beginning of the heap.
  65.  
  66. On the other hand, this approach is realistically impractical... Perhaps a
  67. solution involving sub-zones in your heap would be easier to implement...
  68.  
  69. - Keith Rollin
  70. - Apple Developer Technical Support
  71.  
  72. DSBB: Devs Ask Each Other: General Discussion
  73. 11-12-90
  74.  
  75. This is Terran again: another recent link:
  76.  
  77. Keith "ALINK MOOF" Rollin of MacDTS has made some fantastic progress on a patch
  78. to the memory manager (both 24-bit and 32-bit) on the IIci,fx,lc,&si.  Ask him
  79. for a trial copy of his memory manager init and I bet your problem gets fixed.
  80.  
  81. -Dick Startz
  82. TSP.STARTZ
  83. Developers Ask Each Other: General
  84. 11/20/90
  85.  
  86. So Maybe Keith has finished the patch, in it anywhere on AOL?
  87. Terran,  AOL: TerranVW
  88.  
  89.